1. Field of the Invention
The present invention pertains to transmission of packets in telecommunications networks, and particularly to compression of headers for such packets.
2. Related Art and Other Considerations
In a typical cellular radio system, mobile user equipment units (UEs) communicate via a radio access network (RAN) to one or more core networks. The user equipment units (UEs) can be mobile stations such as mobile telephones (“cellular” telephones) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by a unique identity, which is broadcast in the cell. The base stations communicate over the air interface (e.g., radio frequencies) with the user equipment units (UE) within range of the base stations. In the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks.
One example of a radio access network is the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The UTRAN is a third generation system which in some respects builds upon the radio access technology known as Global System for Mobile communications (GSM) developed in Europe. UTRAN is essentially a wideband code division multiple access (W-CDMA) system. Another example radio access network is GPRS EDGE Radio Access Network (GERAN).
The world of telecommunications is undergoing a shift of paradigm from circuit switched, connection-oriented information transfer towards packet switched, connection-less transfer. Accordingly, the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN) accommodates both circuit switched and packet switched connections. For example, in UTRAN the circuit switched connections involve a radio network controller (RNC) communicating with a mobile switching center (MSC), which in turn is connected to a connection-oriented, external core network, which may be (for example) the Public Switched Telephone Network (PSTN) and/or the Integrated Services Digital Network (ISDN). On the other hand, in UTRAN the packet switched connections involve the radio network controller communicating with a Serving GPRS Support Node (SGSN) which in turn is connected through a backbone network and a Gateway GPRS support node (GGSN) to packet-switched networks (e.g., the Internet, X.25 external networks)
There are several interfaces of interest in the UTRAN. The interface between the radio network controllers (RNCs) and the core network(s) is termed the “Iu” interface. The interface between a radio network controller (RNC) and its base stations (BSs) is termed the “Iub” interface. The interface between the user equipment unit (UE) and the base stations is known as the “air interface” or the “radio interface” or “Uu interface”.
For application independence and to decrease coasts for transport and switching, it is attractive to use the packet-switched Internet Protocol (IP) all the way over the air interface to the end user equipment. In other words, it is advantageous not to terminate the Internet Protocols before the air interface. Previously a major reason for not using Internet Protocols over the air interface has been the relatively large overhead imposed by certain “headers” associated with voice packets (e.g., IP/UDP/RTP headers).
Thus, a major problem with transmitting voice using Internet Protocol over a wireless (e.g., air) interface is the large size of headers of the protocols employed when sending speech data over the Internet. For example, an IPv4 packet with speech data has an IP header, a UDP header, and an RTP header, which all together total 20+8+12=40 octets. With IPv6, the IP header is 40 octets for a total of 60 octets. The size of the speech data depends on the codec, and can be from 15 octets to 30 octets. These relatively large numbers would militate in favor of terminating the IP protocols prior to the air interface, since the IP/UDP/RTP headers require a higher bit rate and cause inefficient use of the expensive radio spectrum
From the foregoing it is appreciated that it is a fundamental challenge to reduce the IP header-related overhead over the relatively error prone and narrow band cellular channels, while maintaining the transparency of all header fields. This challenge has been addressed, with differing degrees of success, using techniques of header compression.
While all header information in a voice packet is needed, there is a high degree of redundancy between header fields in the headers of consecutive packets belonging to the same packet stream, e.g., the same packet flow. Capitalizing upon this observation, header compression algorithms typically attempt to maintain a “context”. The context, maintained at both ends of the channel over which the header compression is performed, is essentially the uncompressed version of the last header transmitted. Compressed headers carry, among other things, changes to the context. Header compression schemes typically have mechanisms for installing context, for detecting when the context is out of date, and for repairing the downstream context when it is out of date.
When having multiple compressed header flows over the same link, there must be some way to determine that a specific compressed header belongs to a specific compressed flow of packets (e.g., to a particular packet stream). This is important since the compressor and decompressor use a state (i.e., the aforementioned context) to determine how it will compress/decompress the header. In a typical scenario of packet transmission, the compressor receives an uncompressed header belonging to a specific packet flow, and uses the correct context for that packet flow to compress that header. The compressed header is transmitted using some kind of mechanism to identify to which flow this specific header belongs. At the other end of the link, the decompressor receives the compressed header, and uses the mechanism to ascertain to which flow or context the header belongs. The decompressor can then use the identified context to decompress the header.
An early header compression scheme, herein known as CTCP, was proposed by Jacobson, V., “Compressing TCP/IP Headers for Low-Speed SerialLinks”, RFC 1144, February 1990. CTCP compresses the 40 octet IP+TCP header to two-four octets. The CTCP compressor detects transport-level retransmissions and sends a header that updates the context completely when they occurs.
A general IP header compression scheme known as IP Header Compression (IPHC) can compress arbitrary IP, TCP, and UDP headers. When compressing non-TCP headers, IPHC does not use delta encoding and is robust. When compressing TCP, the repair mechanism of CTCP is augmented with a link-level nacking scheme which speeds up the repair. IPHC does not compress RTP headers.
A header compression scheme known as CRTP has been proposed for real-time IP services. See, e.g., S. Casner, V. Jacobson, “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links”, RFC 2508, February 1999. CRTP can compress 40 octet IPv4/UDP/RTP headers to a minimum of two octets. For context repair, CRTP relies on existence of an upstream link over which a decompressor sends requests for updating headers. While the context is out of date, all packets received cannot be decompressed.
A header compression scheme known as Robust Header Compression (ROHC) is suitable for cellular usage. See, e.g., C. Borman et al, “Robust Header Compression (ROHC)”, draft-ietf-rohc-rtp-02.txt (work in progress), September 2000. In ROHC, a checksum covering the original (uncompressed) header is included in the compressed header to introduce a reliable way to detect when the context is out of date, and when an attempt to repair the context locally has succeeded. ROHC introduces different compression profiles to handle different kinds of RTP-streams and channel conditions to achieve as high performance as possible. In addition, ROHC includes in its compressed header codes which provide the decompressor with hints about how header fields have changed, e.g., due to loss over the cellular link. In ROHC, the packet type identification is incorporated in the header compression scheme, and thus this functionality is not needed from the link layer. In this regard, the ROHC may have context identifiers (CIDs) of size 0, 1, or 2 bytes.
An undertaking known as the Third Generation Partnership Project (3GPP) has endeavored to evolve further the UTRAN and GSM-based radio access network technologies, including header compression for UDP/IP and TCP/IP headers. One aspect of the 3GPP system which is of importance for header compression schemes is the concept of logically separated channels or radio bearers (instead of completely shared channels [such as, for example, the Internet]). It has been proposed that context identifiers (CIDs) be used to identify which context should be used to decompress a compressed header. See, S. Casner, V. Jacobson, “Compressing IP/UDP/RTP Headers for Low-Speed Serial Links”, RFC 2508, February 1999; and Mikael Degermark, Bjorn Nordgren, Stephen Pink, “IP Header Compression”, RFC 2507, February 1999. In a 3GPP cellular system, there has already been a de-multiplexing of the traffic onto different radio bearers. This separation reduces the need for context identification. Therefore, the number of contexts per radio bearer are relatively small.
The Third Generation Partnership Project (3GPP) Specification 3G TS 25.323 V3.3.0 (2000-09) describes a link layer protocol known as Packet Data Convergence Protocol (PDCP). Some of the main functions of the Packet Data Convergence Protocol (PDCP) are: (1) transfer of packet data protocol user data using services provided by the Radio Link Control (RLC) protocol; and (2) header compression (e.g., compression of redundant control information). The Packet Data Convergence Protocol (PDCP) provides its services by way of PDCP entities at the user equipment unit (UE) or at the relay at the radio network controller (RNC). In its current form (e.g., TS 25.323. v3.3.0), in Packet Data Convergence Protocol (PDCP) every radio bearer is connected to one PDCP entity, and one PDCP entity is connected to one RLC entity. Every PDCP entity uses either zero, one, or several header compression algorithm types with certain parameters, and several PDCP entities may use the same algorithm type.
In Packet Data Convergence Protocol (PDCP), the header compression method is specific for each network layer protocol type. The header compression algorithms and their parameters are negotiated by a Radio Resource Control (RRC) for each PDCP entity and indicated to PDCP through a PDCP Control Service Access Point (PDCP-C-SAP). Compressor and decompressor initiated signalling between peer PDCP entities, during operation, is carried out in the user plane.
As set forth in the 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09), the Packet Data Convergence Protocol (PDCP) features a protocol data unit (PDU) which can be one of three types. The first type is a PDCP-No-Header PDU; the second type is a PDCP Data PDU; the third type is a PDCP SeqNum PDU. Both the PDCP Data PDU and the PDCP SeqNum PDU include a three bit PDU type field and a five bit PID field. A value in the three bit PDU type field indicates whether the PDU is a PDCP Data PDU or a PDCP SeqNum PDU (See, e.g., 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09), Section 8.3.1). The five bit PID field indicates the used header compression and packet type.
A PDCP Data PDU with its three bit PDU type field and five bit PID field as set forth in 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09). Table 1 below is taken from 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09) as showing an example of PID value allocation for the five bit PID field for the PDCP Data PDU. (See, e.g., 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09), Section 8.2.2 and Section 8.3.2).
TABLE 1PID VALUEOptimization MethodPacket Type0No header compression—1RFC2507Full header2RFC2507Compressed TCP3RFC2507Compressed TCP nondelta4RFC2507Compressed non TCP5RFC2507Context State6Method AUncompressed TCP/IP7Method ACompressed TCP/IP8Method BUncompressedIP/UDP/RTP9Method BCompressed IP/UDP/RTP10 . . . 31Unassigned Value—
As described in 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09), Section 5.1.1, for a certain algorithm in a PCDP entity the assignment of PID values starts from (n+1) where n is the number of PID values already assigned to other algorithms. The assignment is done in the order the algorithms are negotiated by the Radio Resource Control. In the example of Table 1, RFC2507 is the first algorithm assigned, Method A was the second algorithm, and Method B was the third algorithm in the PDCP information element exchanged between peer Radio Resource Control entities.
The mechanism mentioned above for differentiating between contexts can be either explicit in the header compression scheme by usage of the context identifiers (CIDs), or implicitly by using a link layer mechanism to differentiate the compressed flows. Usage of explicit CIDs requires extra bits in the compressed headers as in the ROHC technique at the header compression level. On the other hand, usage of implicit context identification at the link layer level such as in Packet Data Convergence Protocol (PDCP) imposes an additional cost at the link layer level.
In a scheme in which there is no PDCP header (See, e.g., 3GPP Specification 3G TS 25.323 V3.3.0 (2000-09), Section 8.2.1), there is no possibility to offer link layer identification of header compression packet types by PDCP. This means that IP header compression (RFC2507) cannot be used when PDCP is configured with the no header option. However, the ROHC algorithm can be used in this mode as the header compressed packet type identification is accomplished with ROHC.
Whereas ROHC can support RTP/UDP/IP compression, the RFC2507 compression algorithm supports (among other things) TCP/IP compression. Likely it will be advantageous in the future in certain applications to mix both RTP/UDP/IP and TCP/IP traffic, as in streaming services (e.g., for example, real-time multimedia applications).
What is needed, therefore, and an object of the present invention, is a technique which facilitates a mixing of packets having headers compressed by one or more compression algorithms which require packet type identification at the link level with other packets having headers compressed by one or more compression algorithms which do not require packet type identification at the link level.